PROJ_01

Event-Driven
Notification Service

Kafka and RabbitMQ powered notification platform supporting Email, SMS and Push delivery with retry mechanisms, dead-letter queues and guaranteed message processing.

JAVA SPRING BOOT KAFKA RABBITMQ POSTGRESQL
VIEW_SOURCE BACK_TO_PROJECTS

OVERVIEW

This project was designed to handle high-volume notifications across multiple delivery channels including Email, SMS and Push. The architecture combines Kafka for event streaming and RabbitMQ for reliable asynchronous task execution. The system includes retry mechanisms, dead-letter queues, channel-based routing and fault-tolerant message handling to ensure reliable notification delivery.

ARCHITECTURE 

+----------------------+
|  CLIENT APPLICATION  |
+----------+-----------+
           |
           v
+----------------------+
| NOTIFICATION API     |
| Spring Boot Service  |
+----------+-----------+
           |
           v
+----------------------+
| KAFKA TOPIC          |
| notification.events  |
+----------+-----------+
           |
   +-------+-------+
   |       |       |
   v       v       v

EMAIL   SMS     PUSH
WORKER  WORKER  WORKER

   |       |       |
   +-------+-------+
           |
           v

+----------------------+
| RABBITMQ QUEUES      |
+----------+-----------+
           |
           v

+----------------------+
| RETRY QUEUE          |
+----------+-----------+
           |
           v

+----------------------+
| DEAD LETTER QUEUE    |
+----------------------+

KEY_FEATURES

Multi Channel Delivery

Supports Email, SMS and Push notifications through independent processing pipelines.

Kafka Event Streaming

Notification requests are published as events, enabling asynchronous processing and scalability.

RabbitMQ Workers

Dedicated workers consume messages reliably and process delivery tasks independently.

Dead Letter Queue

Failed deliveries are isolated into a DLQ for investigation and replay.

KAFKA_WORKFLOW

  1. 1. Client submits a notification request.
  2. 2. Notification API validates payload.
  3. 3. Event is published to Kafka topic.
  4. 4. Consumer groups subscribe independently.
  5. 5. Messages are routed to delivery workers.
  6. 6. Workers acknowledge successful processing.

RABBITMQ_WORKFLOW

  1. 1. Delivery task enters RabbitMQ queue.
  2. 2. Worker consumes task.
  3. 3. Delivery attempted.
  4. 4. Success → ACK message.
  5. 5. Failure → Retry Queue.
  6. 6. Retry exhausted → Dead Letter Queue.

RETRY_STRATEGY

Attempt 01

Initial delivery attempt immediately after queue consumption.

Attempt 02

Failed messages are redirected to retry queues with configurable delay intervals.

Final Failure

Messages exceeding retry limits are moved into the Dead Letter Queue.

DEAD_LETTER_QUEUE

The Dead Letter Queue (DLQ) captures permanently failed notifications and prevents message loss.

ENGINEERING_CHALLENGES

Reliable Delivery

Ensuring notifications are not lost during worker failures required acknowledgement handling, retries and queue durability.

Channel Isolation

Email, SMS and Push channels were isolated into dedicated processing flows to prevent cascading failures.

Scalability

Kafka consumer groups enable horizontal scaling as notification volume increases.

RESULTS

3

DELIVERY CHANNELS

2

MESSAGE BROKERS

DLQ

FAILURE RECOVERY

LESSONS_LEARNED

This project strengthened my understanding of event-driven architecture, asynchronous processing, distributed messaging systems, fault tolerance, retry strategies and scalable backend design. Building the system provided practical experience with Kafka event streaming, RabbitMQ task processing and designing resilient backend services using Spring Boot.

VIEW_SOURCE_CODE

OPEN_GITHUB